The DeceptiClowns

From Left to Right: Kevin Kelly, Satish Jesudas, Drew Bell and Arik Avagyan

Goal of Project:

The objective of the project was to navigate to five (x, y) points in a 10 foot by 10 foot course. Five golf balls, either orange or blue, were placed randomly about the course. The robot was required to collect at least two balls while navigating obstacles along the route to the (x,y) points. The score was based on the total time taken to navigate the course and collect at least one blue golf ball and one orange golf ball. Each ball collected in addition to the two required subtracted 20 seconds from the score. Twenty seconds per ball were subtracted for each ball where the position and color were sent from the robot to the MATLAB interface.

Strategy:

Robot Navigation:

The algorithm for the navigation of the robot was developed using Code Composer. The strategy for navigating the robot consisted of four main parts:

1) Obstacle avoidance

2) Navigation to specific destinations

3) Design of the gripper to collect the two different colored golf balls in two different pockets

4) Collection of the golf balls and dropping them at the specified locations

The obstacle avoidance was our primary goal. The Ladar distance readings of the LADAR sensor on the robot were used to detect the obstacles. The front readings were used to detect an obstacle in front and depending on whether the minimum of the left half or the right half of the front distance readings was smaller, the robot would do left wall following or right wall following respectively. Additional statements were added to this part of the code to account for special obstacle cases that might have occurred in the maze or when the robot was outside of the maze.

The code for navigating the robot to specific destinations was already available, but it had to be combined with obstacle avoidance. This was accomplished by using Bug 2 algorithm. The vector from the old destination position to the new destination position was calculated and the vector from the current position of the robot to the new destination was calculated. The angle between the two vectors was calculated and if the angle was less than a certain threshold, the robot would break from wall following and move towards the destination point. In the case that the destination is beyond the wall that the robot is following, the vector that was perpendicular to the direction of the velocity of the robot was calculated. This vector was used to measure the angle between that vector and the vector from the current position of the robot to the next destination. If that angle was greater than a certain threshold, the robot would not break away from the wall even if it was within the angle range to move towards the destination. Additionally the vector magnitude from the current position to the new destination was calculated every time the robot encountered a front wall when moving to the destination. If after wall following the robot would come within the angle range so that it could break away from the wall and move towards the destination again, the magnitude of the vector from the current position of the robot to the new destination was compared to the magnitude when the robot encountered the front wall. If the current magnitude was greater than the old magnitude by 2 tiles, the robot would continue wall following. This was done to prevent the robot from falling into an endless loop that could occur for some particular arrangements of obstacles.

The gripper designed to collect the golf balls used two RC servos to lift the pocket doors. There was a good chance that the golf ball would bounce off the robot and not be collected. The RC servos were used to only open the door when dropping the golf balls in the specified locations. To accomplish this, flap doors were taped to the gripper that would easily open in both directions with the ball slightly pushing on them. RC servos were connected to small doors which, when closed, would prevent the flap door from opening in the outside direction. Therefore, the golf balls could go in but could not come out unless the RC servos opened the doors to allow the flap door to move in both directions.

The fourth task was accomplished with the following strategy. A toggle flag was used in the vision processing code to shift between looking for blue balls and orange balls every time it was called. If, for example, an orange ball was detected a flag was used to stop the toggle so that the robot would look only for orange balls until the flag was cleared. The robot would turn and move towards the ball until the column coordinate of its centroid on the camera would correspond to a specific value which was chosen to make sure the ball was collected in the correct pocket. Additionally to account for the special case that the robot would see 2 orange balls, the algorithm was adjusted to make the robot collect the first ball before moving to the next one. Once the balls were collected the toggle was enabled so the robot would continue looking for both types of balls. After the robot had cleared all destinations it would check to see if it had enough balls collected to drop them off. After dropping the golf balls in the specified locations, it would go back into the maze to look for additional balls.

Graphical User Interface:

The GUI for the robot was developed using the Matlab Graphical User Interface Development Environment. There are four main goals of the GUI application:

1) Track the robot in the course

2) Draw the outline of the course

3) Display (x,y) and color of balls collected

4) Update robot parameters from the GUI

The first three goals were accomplished using a two-stage process. The first stage is an initialization where we set up the course in a my-plot alongside a data table that will later be used to display collected ball data. There are other informational displays for the (x,y), and orientation of the robot as well as some buttons that allow us to make and break a connection to the IP socket of our robot car. The next stage serves as an update step that executes at a timed interval. In order to get this to work, the robot's Linux processor must be running the VBDSPComm application. When Matlab secures a connection to the robot with a running VBDSPComm server, the GUI's data table is updated with the position of each ball collected.

The key to getting an accurate xy-position lies in the robot's navigation algorithm. As the robot moves between each of the 5 state positions, it is constantly checking for blue and orange pixels on alternating executions of the runtime cycle. A group of blue or orange pixels is only recognized as a ball if the grouping of pixels passes a certain threshold. As soon as a ball is identified, the robot calculates the xy-position of the ball and then four pieces of data are stored in an array that will be sent to shared memory ultimately being sent to the GUI. These four variables are the x position, y position, color of the ball, and the number of balls collected. But instead of sending the array off to shared memory as soon as the balls are seen, the robot waits for a 500 millisecond delay that allows the robot enough time to collect the ball, ensuring that the only data being sent is for that of collected balls.

Within the coding of the GUI there are checks to ensure that only one row of the ball data table is written at a time. Essentially this is done by checking if the old ball count is not equal to the new ball count, i.e. we have a new ball to add to the table. The word table is used loosely here because an attempt at using a table within the Matlab GUI was fruitless so a solution was put together that allowed for updating text boxes with the data of each ball. These boxes were simply organized in a row-column pattern that gives the appearance of a table. In other words, the elegant solution of looping through each row and column of a table was scrapped for a more brute force, yet much more immediate solution.

It should be noted that not all goals of this GUI were accomplished. We do not have a capability to update robot parameters from the GUI. In transitioning from VB to Matlab, the decision was made to tackle the first three of the four goals mentioned above. An attempt to meet this last goal was hindered by time and a lack of understanding of how Matlab communicates with the robot.

Photos and Videos:

` Matlab in Action

The Source Code and Project Files